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Abstract 

The  terms  architecture,  design,  and  implementation  are 
typically  used  informally  in  partitioning  software  specifi¬ 
cations  into  three  coarse  strata  of  abstraction.  Yet  these 
strata  are  not  well-defined  in  either  research  or  practice, 
causing  miscommunication  and  needless  debate. 

To  remedy  this  problem  we  formalize  the  Intension  and 
the  Locality  criteria,  which  imply  that  the  distinction  be¬ 
tween  architecture,  design,  and  implementation  is  quali¬ 
tative  and  not  merely  quantitative.  We  demonstrate  that 
architectural  styles  are  intensional  and  non-local;  that 
design  patterns  are  intensional  and  local;  and  that  imple¬ 
mentations  are  extensional  and  local. 

If  people  do  not  believe  that  mathematics  is  simple,  it  is  only 
because  they  do  not  realize  how  complicated  life  is. 

—  J.  H.  von  Neumann 

1.  Introduction 

In  their  seminal  article.  Perry  and  Wolf  [24]  developed 
“an  intuition  about  software  architecture  through  analo¬ 
gies  to  existing  disciplines.”  Building  on  this,  Shaw  and 
Garlan  [31]  suggest  that  “software  architecture  involves 
the  description  of  elements  from  which  systems  are  built.” 
A  considerable  body  of  work,  stemming  back  to  DeRemer 
and  Kron’s  module  interconnection  languages  (MIL)  [7], 
focuses  on  the  specification,  construction,  and  analysis  of 
large  software  systems  defined  by  these  terms  (e.g.,  [26], 
[21],  [15]).  For  example,  architecture  description  lan¬ 
guages  (ADL)  combine  a  formal  specification  language 
with  tools  supporting  the  construction  and  analysis  of 
software  systems  from  such  specifications. 

Seeking  to  separate  architectural  design  from  other  de¬ 
sign  activities,  definitions  of  software  architecture  stress 
the  following; 

■  “Architecture  is  concerned  with  the  selection  of  archi¬ 
tectural  elements,  their  interaction,  and  the  constraints 
on  those  elements  and  their  interactions...  Design  is 
concerned  with  the  modularization  and  detailed  inter¬ 
faces  of  the  design  elements,  their  algorithms  and  pro- 
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cedures,  and  the  data  types  needed  to  support  the  archi¬ 
tecture  and  to  satisfy  the  requirements.”  [24] 

■  Software  Architecture  is  “concerned  with  issues  ...  be¬ 
yond  the  algorithms  and  data  structures  of  the  compu¬ 
tation.”  [16] 

■  “Architecture  ...  is  specifically  not  about  . . .  details  of 
implementations  (e.g.,  algorithms  and  data  structures.) 
. . .  Architectural  design  involves  a  richer  collection  of 
abstractions  than  is  typically  provided  by  OOD.”  [23] 

■  “Architecture  f  Design?  ...  Design  is  an  activity.  Ar¬ 
chitecture,  or  architectural  design,  is  design  at  a  higher 
level  of  abstraction.”  [18] 

■  Architecture  focuses  on  the  externally  visible  proper¬ 
ties  of  software  “components.”  [2] 

In  suggesting  typical  “architectures”  and  “architectural 
styles”,  existing  definitions  consist  of  examples  and  offer 
anecdotes  rather  then  provide  unambiguous,  clear  notions. 

In  practice,  the  terms  “architecture”,  “design”  and  “im¬ 
plementation”  appear  to  connote  varying  degrees  of  ab¬ 
straction  in  the  continuum  between  complete  details  (“im¬ 
plementation”),  few  details  (“design”),  and  the  highest 
form  of  abstraction  (“architecture”).  But  the  amount  of 
detail  alone  is  insufficient  to  characterize  the  differences, 
because  architecture  and  design  documents  often  contain 
information  that  is  not  explicit  in  the  implementation  (e.g., 
design  constraints,  standards,  performance  goals)  and 
therefore  they  cannot  result  from  mere  omission  of  detail. 
Thus,  we  would  expect  a  distinction  to  be  qualitative  and 
not  merely  quantitative.  A  clear  distinction  has  remained 
elusive  and  this  lack  of  distinction  is  the  cause  of  much 
muddy  thinking,  imprecise  communication,  and  wasted, 
overlapping  effort. 

As  a  result,  architecture  is  often  used  as  a  mere  syno¬ 
nym  for  design.  For  example,  the  “Siemens”  catalogue  [4] 
defines  “architectural  patterns”  that  are  in  par  with  “de¬ 
sign  patterns”  defined  by  the  “Gang  of  Four”  [14]. 

Confusion  also  stems  from  the  use  of  the  same  specifi¬ 
cation  language  for  both  architectural  and  design  specifi¬ 
cations.  For  example,  the  Software  Engineering  Institute 
(SEI)  classifies  UML  [3]  as  an  architectural  description 
language  [30],  and  it  has  become  the  industry  de  facto 
standard  ADL,  although  UML  was  specifically  designed 
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to  manifest  detailed  design  decisions  (and  this  is  its  most 
common  use). 

Confusion  also  exists  with  respect  to  the  artifacts  of 
design  and  implementation.  UML  class  diagrams  [3],  for 
instance,  are  a  prototypical  artifact  of  the  design  phase. 
Nonetheless,  class  diagrams  may  accumulate  enough  de¬ 
tail  to  allow  code  generation  of  very  detailed  programs,  an 
approach  that  is  promoted  by  CASE  tools  such  as  Ra¬ 
tional  Rose®  [28]  and  System  Architect®  [25].  Using  the 
same  specification  language  further  blurs  the  distinction 
between  artifacts  of  the  design  (class  diagrams)  from  the 
implementation  (source  code.) 

Intended  contribution.  Why  are  we  interested  in  such 
distinctions?  Naturally,  a  well-defined  language  improves 
our  understanding  of  the  subject  matter.  With  time,  terms 
that  are  used  interchangeably  lose  their  meaning  and  end 
up  as  mere  platitudes,  resulting  inevitably  in  ambiguous 
descriptions  given  by  developers,  and  significant  effort  is 
wasted  in  discussions  of  the  form  “by  design  I  mean... 
and  by  architecture  I  mean...”  The  formal  ontology  we 
provide  can  serve  as  the  ultimate  reference  point  for  these 
discussions. 

The  contribution  of  this  paper  is  to  provide  insight  on 
the  largely  informal  dialectic  by  appealing  to  both  intui¬ 
tion  and  to  formal  ontology.  By  putting  these  terms  on  a 
solid  footing  not  only  do  we  disambiguate  the  progres¬ 
sively  murky  discourse  in  “architectural  specifications” 
but  provide  a  foundation  for  formal  reasoning  and  analy¬ 
sis,  as  well  as  a  firm  foundation  for  informal  “chalk-talk” 
discussions.  Finally,  tools  supporting  design  and  architec¬ 
tural  specifications,  where  intuitive  perceptions  are  insuf¬ 
ficient,  will  benefit  by  accurately  defining  this  distinction. 

Many  of  the  required  definitions  were  rendered  infor¬ 
mal  and  the  proofs  were  omitted  in  this  version  of  our 
work.  The  interested  reader  can  find  the  complete  defini¬ 
tions  in  [12],  and  additional  details  on  the  design  models 
formalism  can  be  found  in  [9].  Instead,  we  argue  our 
points  with  informal  illustrations  and  discussions. 

1 . 1  The  Intension/Locality  Thesis 

To  elucidate  the  relationship  between  architecture,  de¬ 
sign,  and  implementation,  we  distinguish  at  least  two 
separate  interpretations  for  abstraction  in  our  context: 

Intensional  (vs.  extensional)  specifications  are  “ab¬ 
stract”  in  the  sense  that  they  can  be  formally  characterized 
by  the  use  of  logic  variables  that  range  over  an  unbounded 
domain; 

Non-local  (vs.  local)  specifications  are  “abstract”  in 
the  sense  that  they  pervade  all  parts  of  the  system  (as  op¬ 
posed  to  being  limited  to  some  part  thereof). 


Both  of  these  interpretations  contribute  to  the  distinc¬ 
tion  among  architecture,  design,  and  implementation. 
This  combination  of  these  interpretations  leads  us  to  the 
intension/locality  thesis: 

(i)  Architectural  specifications  are  intensional  and 
non-local; 

(ii)  Design  specifications  are  intensional  but  local; 
and 

(iii)  Implementation  specifications  are  both  exten¬ 
sional  and  local. 

The  intension/locality  thesis  is  summarized,  for  easier 
reference,  in  Table  1. 


Table  1.  The  Intension/Locality  Thesis 


Architecture 

Intensional 

Non-local 

Design 

Intensional 

Local 

Implementation 

Extensional 

Local 

1 .2  Structure  of  This  Paper 

The  intension/locality  thesis  can  be  understood  cor¬ 
rectly  only  in  the  context  of  the  ontology  provided  below. 
In  Section  2  we  define  design  models,  which  are  crucial  to 
the  remainder  of  our  discussion.  Design  models  are  ab¬ 
stractions  which  allow  a  formal  “meaning”  assigned  to 
programs,  also  called  “denotation”.  This  formalism  allows 
us  to  determine  whether  a  specification  is  “satisfied”  by  a 
program. 

In  Section  3,  we  formally  define  the  Intension  criterion 
and  the  Locality  criterion.  We  distinguish  our  interpreta¬ 
tion  for  “intensionality”  from  the  accepted  usage,  as  we 
define  it  in  terms  of  design  models. 

Sections  4,  5,  and  6,  provide  case  studies  in  applying 
the  Intension  and  Locality  criteria  using  our  formal  ontol¬ 
ogy.  In  Section  4  we  demonstrate  that  implementations  in 
any  programming  language,  including  generics  and  C-H- 
templates  are  extensional  and  local.  In  Section  5  we  show 
that  design  patterns,  such  as  the  Factory  Method,  and  de¬ 
sign  specifications,  such  as  the  Enterprise  JavaBeans™ 
and  Java™  Swing’s  MVC,  are  intensional  and  local.  In 
Section  6  we  demonstrate  that  architectural  styles  such  as 
Pipes  and  Filters  and  Layered  Architecture  are  intensional 
and  non-local,  and  so  is  the  Law  of  Demeter. 

In  Section  7,  we  discuss  some  of  the  ramifications  of 
our  criteria.  The  discussion  of  UML  class  diagrams  in 
Section  7.2  reveals  that  class  diagrams  have  a  separate 
place  in  the  hierarchy  of  abstractions  we  describe.  Section 
8  summarizes  the  contributions  of  this  paper. 


2.  Setting  the  Scene 

In  this  section,  we  illustrate  the  formal  ontology  that 
underlies  our  discussion.  This  ontology  is  based  on  giving 
an  abstract  “meaning”  to  programs  using  design  models. 

2. 1  Design  Models 

Turing  and  random-access  machines  provide  robust 
computational  models  that  are  primarily  suitable  for  rea¬ 
soning  about  algorithms.  Other  computational  models  and 
formalisms  (e.g.,  Petri  nets,  statecharts,  and  temporal 
logic)  facilitate  reasoning  about  certain  behavioral  proper¬ 
ties. 

The  discussion  in  architectural  and  design  specifica¬ 
tions,  however,  involves  reasoning  on  constructs  such  as 
classes,  methods,  and  function  calls.  Most  other  formal¬ 
isms  incorporate  too  much  implementation  detail  and  do 
not  allow  a  discussion  in  the  appropriate  level  of  abstrac¬ 
tion.  As  we  seek  to  establish  the  relation  between  architec¬ 
tural  or  design  specifications  and  implementations,  we 
base  our  discussion  on  a  different  formalism,  one  which 
abstracts  programs  to  a  more  convenient  representation. 

Eden  and  Hirshfeld  [11]  demonstrate  how  to  model 
source  code  as  design  models,  which  are  first  order,  finite 

Table  2.  A  Java™  program  and  its  denotation 
(adapted  from  [9].) 

abstract  class  Decorator  { 
public  void  Draw ( ) ; 

} 

class  BorderDecorator  extends  Decorator  { 

public  void  Draw ( )  { 

Decorator . Draw ( ) ; 

} 

private  int  BorderWidth; 

^ _ 

The  design  model  of  this  program  consists  of  the  following: 
Atoms: 

“class”  atoms:  {Decorator,  BorderDecorator,  int, 
void},  “Method”  atoms:  {BorderDecorator  .  Draw, 
Decorator . Draw  } 

Relations: 

A  bstract  (Decorator ) 

Member  (Decorator .  Draw,  Decorator ) 

Member (BorderDecorator . Draw,  BorderDecorator ) 
Inherit  (BorderDecorator ,  Decorator ) 
i?e/erence (BorderDecorator,  int^ 

Invoke (BorderDecorator . Draw,  Decorator . Draw ) 
ReturnType(Decorator  .Draw,  void) 

Return  Type (BorderDecorator . Draw,  void} 


structures  in  mathematical  logic  [1].  Informally,  a  design 
model  tn  [11]  consists  of  a  set  of  atoms  and  a  set  of  rela¬ 
tions  among  those  atoms. 

Table  2  depicts  a  detailed  example  of  a  trivial  Java'’''^ 
program  and  a  design  model  that  represents  it.  As  this 
example  demonstrates,  an  object-oriented  program  is  ab¬ 
stracted  to  a  collection  of  classes  and  methods  (also  rou¬ 
tines  or  function  members)  and  their  relations.  Atoms  rep¬ 
resent  classes  and  methods  that  were  defined  in  the  pro¬ 
gram,  such  as  the  class  Decorator  and  the  method 
Decorator .  Draw.  Relations  represent  their  correlations, 
such  as 

/n/ierif  (Border  Decor  at  or,De  cor  at  or  )  (1) 

Note  that  design  models  are  abstractions  which  were 
made  to  reflect  certain  structural  aspects  of  computer  pro¬ 
grams  that  are  relevant  to  the  discussion  in  software  de¬ 
sign  theory.  Obviously,  this  representation  limits  the  type 
of  reasoning  we  may  perform  to  properties  that  are  rele¬ 
vant  to  the  discussion  in  classes,  methods,  and  their  inter¬ 
dependencies,  as  opposed  to  the  discussion  in  dynamic 
properties  such  as  fairness  and  complexity. 

2.2  Specifications  and  Instances 

In  this  subsection,  we  discuss  specifications  and  pro¬ 
grams,  and  illustrate  how  the  two  correlate.  We  make 
some  reasonable  assumptions  on  the  languages  used  to 
write  specifications. 

Let  us  designate  SPEC  as  the  set  of  formal  languages 
of  any  order  [1].  Let  SPEC*  designate  the  set  of  all  ex¬ 
pressions  made  in  some  language  in  SPEC.  A  specifica¬ 
tion  is  an  element  of  SPEC* . 

SPEC  includes  familiar  specification  languages  such 
as  Z  [32],  as  demonstrated  in  formulas  (5.1)  and  (5.2), 
and  LePUS  [8],  as  demonstrated  in  formula  (4).  SPEC 
also  includes  programming  languages  such  as  Eiffel,  C-H-, 
and  Java^*^.  Naturally,  SPEC  is  not  restricted  to  known 
programming  or  specification  languages. 

A  specification  is  only  useful  if  we  can  determine 
whether  it  is  “satisfied”  or  not.  Having  chosen  design 
models  as  our  semantics  we  wish  to  ask:  Does  this  pro¬ 
gram  satisfy  our  specification?  To  answer  this  question, 
consider  for  example  the  following  trivial  design  specifi¬ 
cation: 

Inherit(x,y)  (2) 

Expression  (2)  contains  two  free  variables:  x,  y.  We 
say  that  it  can  be  satisfied  by  any  pair  of  atoms  that  belong 
to  the  relation  Inherit.  Eor  example,  from  expression  (1) 
we  conclude  that  the  pair 

(BorderDecorator, Decorator}  satisfies  expression 

(2). 


Thus,  we  can  say  that  the  pair  of  atoms 
(^BorderDecorator,Decorator/)  is  an  instance  of  (2), 
and  that  the  design  model  depicted  in  Table  2  instantiates 
expression  (2).  A  more  formal  definition  of  instance  ap¬ 
pears  in  [12]  and  in  [9]. 

From  this  example,  it  should  be  clear  that  an  instance 
is  not  the  same  as  a  “program”.  Depending  on  the  specifi¬ 
cation,  a  program  may  contain  zero,  one,  or  any  number 
of  instances.  The  following  subsection  formalizes  the  no¬ 
tion  of  a  program. 

2.3  Programs  and  their  Denotation 

We  expect  a  “program”  to  be  a  specification  that  is  as¬ 
sociated  with  only  one  design  model.  The  association  be¬ 
tween  “real”  programs  and  design  models  is  provided  by 
the  denotation  function.  Loosely  speaking,  a  denotation 
function  D  has  these  properties: 

■  Its  domain,  denoted  T^d  ,  is  a  subset  of  SPEC*', 

■  D  associates  each  element  if  with  exactly  one  design 

model  (its  denotation)  which  instantiates  f>. 

Typically,  the  domain  of  D  contains  expressions  in 
programming  languages,  such  as  C-n-  and  Eiffel.  More 
formally,  a  program  is  an  element  in  Po  .  Every  design 
model  typically  denotes  infinitely  many  programs.  Eigure 
1  illustrates  the  denotation  associated  between  certain 
specifications  (“programs”)  and  design  models.  Table  2 
illustrates  the  denotation  of  a  simple  JavaT*^  program  and 


Observe  that  the  set  of  programs  P\y  is  only  a  small 
subset  of  the  expressions  in  SPEC*,  and  that  there  are 
many  expressions  in  SPEC*  that  are  instantiated  by  more 
than  one  design  model 


We  now  have  a  well-defined  notion  of  programs  and 
specifications.  In  combination  with  the  definition  of  an 
“instance”  of  a  specification,  we  can  conclusively  deter¬ 
mine  whether  a  program  satisfies  a  given  specification: 

Definition  I.  We  say  that  a  program  TT  satisfies  specifica¬ 
tion  ip  iff  the  design  model  of  TV  instantiates  p. 

This  means  that,  for  example,  the  Java'’''^  program  de¬ 
picted  in  Table  2  satisfies  expression  (2). 

In  the  following  sections,  we  will  set  apart  architecture, 
design,  and  implementation  specifications  based  on  ob¬ 
serving  properties  of  the  groups  of  programs  that  satisfy 
each  specification. 

3.  The  Intension/Locality  Criteria 

We  will  now  define  the  concepts  of  intension  and  lo¬ 
cality,  which  will  be  applied,  both  formally  and  infor¬ 
mally,  to  selected  specifications  in  the  following  sections. 

3.1  The  Intension  Criterion 

Perry  and  Wolf  [24]  have  established  that  architectural 
specifications  must  be  made  in  intensional  terms.  Speak¬ 
ing  of  the  desired  properties  of  an  ideal  specification  lan¬ 
guage  for  software  architecture  they  write:  “We  want  a 
means  of  supporting  a  ‘principle  of  least  constraint’  to  be 
able  to  express  only  those  constraints  in  the  architecture 
that  are  necessary  at  the  architectural  level  of  the  system 
description”.  It  constrains  only  what  it  needs  to,  in  terms 
of  properties  imposed  over  free  variables. 

Traditionally,  intensional  specifications  define  a  con¬ 
cept  via  a  list  of  constraints.  Eor  example,  mathematical 
concepts  are  usually  defined  intensionally.  Eor  instance, 
“A  prime  number  is  a  number  that  divides  only  by  itself 
and  by  the  number  1”.  In  contrast,  the  North  Atlantic 
Treaty  defines  the  set  of  NATO  members  extensionally, 
namely,  by  itemizing  its  members:  United  States,  United 
Kingdom,  Norway,  and  so  forth. 

The  notion  of  intensionality  defined  below  diverges 
slightly  from  the  philosophical  concept.  We  say  that  a 
specification  is  intensional  if  and  only  if  it  has  an  un¬ 
bounded  number  of  instances: 

Definition  11.  We  say  that  a  specification  is  intensional  iff 
there  are  infinitely -many  possible  instances  thereof.  Con¬ 
versely,  all  other  expressions  are  extensional. 

It  immediately  follows  (as  shown  in  [12])  that  inten¬ 
sional  specifications  are  also  satisfied  by  infinitely  many 
design  models  and  by  infinitely  many  programs. 


3.2  The  Locality  Criterion 


Monroe  et.  al  [23]  argue  that  “Architectural  designs  are 
typically  concerned  with  the  entire  system.”  Similarly,  we 
observe  that  an  architectural  style,  which  pervades  a  sys¬ 
tem  [16],  manifests  a  property  that  is  shared  across  mod¬ 
ules  of  the  system.  This  intuition  motivates  the  Locality 
criterion;  What  distinguishes  architectural  from  design 
specifications  is  that  architectural  specifications  must  be 
met  by  every  extension  of  the  program. 

As  a  simple  example,  consider  the  rule  of  a  “universal 
base  class”.  Although  the  language  does  not  require  it, 
several  C-n-  class  libraries  (e.g.,  NIHCL  and  Microsoft’s 
MFC)  are  designed  by  this  rule.  Formally,  this  property 
can  be  expressed  as  follows: 

Vc  •  Class (c)^  Inherit*  (c, Oh  ject)  (3) 

(Where  Inherit*  is  the  transitive  closure  of  the  binary 
relation  Inherit.)  The  intension/locality  thesis  argues  that 
Universal  Base  Class  is  architectural  because  (a)  it  is  in- 
tensional  and  (b)  it  pervades  all  parts  of  the  system,  i.e., 
every  class  must  be  bound  to  Ob  ject. 

Subsumption.  The  formalization  of  the  locality  criterion 
requires  the  notion  of  subsumption.  Informally,  we  say 
that  structure  U  subsumes  structure  Ttl  if  Ttl  is  a  “sub¬ 
model”  of  tf ,  or  that  U  is  an  “extension”  to  Ttl . 

Definition  III.  We  say  that  a  specification  is  local  iff 
the  following  condition  holds: 

If  Lp  is  satisfied  in  some  design  model  Ttl  then  every 
design  model  that  subsumes  Ttl  also  satisfies  p. 

Essentially,  Definition  III  states  that  an  expression  is 
local  if  it  can  be  satisfied  in  “some  corner”  of  our  program 
without  this  being  affected  in  how  the  rest  of  the  program 
is  like. 

In  the  following  sections,  we  apply  the  Intension  and 
Locality  criteria  to  selected  specifications  to  illustrate  the 
difference  between  programs,  design  specifications,  and 
architectural  specifications. 

4.  Implementations 


of  instances,  namely,  to  be  “intensional”.  The  same  ap¬ 
plies  to  design  patterns.  But  what  about  other  forms  of 
specifications?  Can  programs  be  intensional? 

Prima  facie,  it  appears  that  some  programming  specifi¬ 
cations  (such  as  Ch-h-  templates  and  Eiffel  generics)  might 
also  be  intensional.  This  is  not  true  in  the  context  of  de¬ 
sign  models'.  As  demonstrated  in  Corollary  1,  specifica¬ 
tions  in  any  programming  language,  including  generics 
and  interpreted  code  are,  under  the  assumptions  provided 
above,  purely  extensional: 

Corollary  I.  templates  are  extensional. 

To  illustrate  this,  consider  the  design  model  of  a  C-H- 
program  with  templates,  such  as  shown  in  Table  3. 

Table  3.  A  C-i-i-  program  and  its  denotation 

template  <class  C>  class  Stack 
{/*  ...  /*} 
int  main ( )  { 

Stack<int>  si; 

return  0 ; 

J _ 

This  program  is  interpreted  by  only  one  design  model, 

which  consists  of  the  following: 

Atoms: 

“Class”  atoms:  {stack,  si}  "Method"  atoms:  {main} 
Relations: 

Generic  (stacV. ) 

Instantiate  (stack,  si,  int} 

Return(main,  int} 

Corollary  1  demonstrates  that  although  generics  may 
be  viewed  as  intensional  with  respect  to  other  semantic 
frameworks,  e.g.,  because  they  can  be  used  to  define  other 
concrete  constructs,  the  ontology  we  have  provided  as¬ 
signs  then  with  only  one  “interpretation”.  The  reason  is 
that  the  formal  semantics  we  chose  for  the  representation 
of  programs  are  design  models,  which  are  more  abstract 
than  the  machine  code  generated  from  compilation  and 
from  other  formal  frameworks. 

To  recap,  the  formal  framework  provided  in  Section  2 
guarantees  that  expressions  in  all  conventional  program¬ 
ming  languages  are  extensional. 


It  immediately  follows  from  the  Intension  criterion  (as 
shown  in  [12])  that  intensional  specifications  are  also  sat¬ 
isfied  by  infinitely  many  design  models  and  by  infinitely 
many  programs.  This  leads  us  to  prove  part  (iii)  of  the 
intension/locality  thesis: 

The  lemma  of  “extensions”:  Programs  are  extensional 
specifications. 

Eollowing  the  ‘principle  of  least  constraint’,  we  expect 
architectural  specifications  to  have  an  unbounded  number 


5.  Design  Specifications 

By  part  (ii)  of  the  intension/locality  thesis,  design 
specifications  should  be  local  and  intensional.  Since  de¬ 
sign  specifications  are,  in  practice,  defined  informally,  we 
begin  section  with  exploring  the  intuition  behind  our  the¬ 
sis.  Eor  the  purpose  of  the  formal  analysis  which  follows, 
however,  we  make  use  of  formal  specifications  and  apply 
them  to  widely  recognized  designs. 


5 . 1  Design  Patterns 

In  this  subsection,  we  focus  on  an  example  drawn  from 
the  published  patterns  literature.  This  allows  us  to  test  our 
ideas  on  some  of  the  most  widely  used  design  specifica¬ 
tions. 

Coplien  and  Schmidt  [5]  argue  that  “design  patterns 
capture  the  static  and  dynamic  structures  of  solutions  that 
occur  repeatedly  when  producing  applications  in  a  par¬ 
ticular  context”.  Stripped  from  the  context  of  a  particular 
application,  design  patterns  represent  categories  of  solu¬ 
tions,  each  pattern  has  an  unbounded  number  of  imple¬ 
mentations  (as  implied  by  the  very  choice  of  the  name 
“pattern”).  Thus,  they  are  expected  to  be  intensional. 

Design  patterns  are  commonly  perceived  as  “less  ab¬ 
stract”  than  architectural  specifications.  For  example,  they 
are  commonly  referred  to  as  “microarchitectures”  [29], 
that  is,  as  if  they  were  like  architectures  that  only  apply  to 
a  limited  module.  Using  our  terminology,  we  thus  expect 
them  to  be  local. 

Consider,  for  example,  the  Factory  Method  design  pat¬ 
tern  [14].  Essentially,  the  pattern’s  solution  offers  three 
sets  of  participants: 

1 .  A  set  of  product  classes 

2.  A  set  of  factory  classes 

3.  A  set  of  factory  methods 

The  collaborations  between  these  participants  are  con¬ 
strained  as  follows: 

4.  All  factory  methods  share  the  same  signature  (thereby 
allowing  for  dynamic  binding),  and  each  is  defined  in  a 
different /actory  class. 

5.  Each /flctory  method  produces  instances  of  exactly  one 
products  class. 

Eigure  2  illustrates  the  general  notion  of  the  pattern. 
Observe  that  the  set  of  (factory-i,  factory-method-i, 
product-i)  triplets  is  unbounded,  because  the  number  of 
possible  factory  and  product  classes  is  not  bounded. 


factory- 1 

)  Produce  ^ 
\method-ly 

product-1 

factory-n 

^^''^Member''^^^  ]  Produce  ^ 

\method-ri^ 

product-n 

Figure  2.  The  general  structure  of  the  “Factory 
Method”  pattern 


Eor  the  discussion  in  design  patterns  we  use  LePUS,  a 
formal  specification  language  for  object-oriented  design, 
which  is  defined  in  detail  in  [8].  The  five  statements  in  the 
above  listed  definition  of  the  Eactory  Method  are  formally 
expressed  by  expressions  (4.1)  to  (4.5)  as  follows: 


Products  :  P(C)  (4.1) 

Factories  :  P(C)  (4.2) 

Factory  Methods  :  P(F)  (4.3) 

Clan(FactoryMethods, Factories)  (4.4) 

Produce*^  (FactoryMethods, Products)  (4.5) 


Expressions  (4.1)  through  (4.3)  declare  two  sets  of 
classes  and  one  set  of  methods.  Expression  (4.4)  indicates 
that  the  pair  (Factory Methods, Factories)  satisfies 
the  predicate  Clan,  meaning  that  - 

■  All  “factory  methods”  share  the  same  signature  (i.e., 
they  share  the  same  dispatch  table); 

■  The  relation  MemberOf  is  a  bijection  (i.e.,  one-to-one 
and  onto  function)  between  the  sets  FactoryMethods 
and  Factories. 

Einally,  expression  (4.5)  indicates  that  the  ground  rela¬ 
tion  Produce  is  a  bijective  function  between  the  set 
FactoryMethods  and  the  set  Products. 

Corollary  2.  “Factory  method”  is  intensional  and  local. 

The  composite  expression  (4.1)  to  (4.5)  is  evidently  in¬ 
tensional,  since  each  one  of  the  free  variables  Products 
and  Factories  (FactoryMethods)  can  be  instantiated 
by  any  number  of  classes  (methods).  To  show  that  it  is 
local,  observe  that  if  a  design  model  TIT  satisfies  it  then  it 
incorporates  an  instance  of  the  pattern.  It  is  then  easy  to 
show  that  any  proper  “extension”  to  TIT  (i.e.,  any  design 
model  that  subsumes  it)  also  contains  the  same  instance  of 
the  Eactory  Method,  namely,  the  same  set  of  atoms  and 
relations  that  satisfied  the  pattern  in  TIT . 

The  same  line  of  reasoning  can  be  applied  to  the  speci¬ 
fications  of  most  of  the  design  patterns  from  the  Gamma 
et.  al  [14]  catalogue,  such  as  the  specifications  in  [8]. 

5.2  Other  Design  Specifications 

The  place  of  other  design  specifications  within  the  in¬ 
tension/locality  classification  may  be  less  obvious  then 
that  of  design  patterns.  Thus,  we  have  carried  out  our 
analysis  on  the  formal  rendering  of  two  additional  design 
specifications:  MVC  (Model-View-Controller)  “usage 
pattern”  in  JavaT*^  Swing  class  library,  and  of  Enterprise 
JavaBeans™. 

In  lack  of  space,  we  cannot  quote  here  the  formal 
specifications  but  only  the  results  of  our  analysis.  The 
interested  reader  may  find  both  specifications  in  [10],  and 
the  complete  proof  for  this  conclusion  in  [12].  We  can 
report  that  our  analysis  confirms  that,  as  predicted  by  the 
intension/locality  thesis,  both  specifications  fall  under  the 
“design”  category,  namely,  they  are  intensional  and  local. 


6.  Architectural  Specifications 

In  this  section,  we  demonstrate  that,  as  predicted  by  the 
intension/locality  thesis,  two  classic  architectural  styles 
are  both  intensional  and  non-local.  We  also  demonstrate 
that  the  Law  of  Demeter  is  architectural. 

6. 1  Layered  Architecture 

Garlan  and  Shaw  [16]  describe  the  layered  architec¬ 
ture  such  that  “An  element  of  layer  k  may  depend  only  on 
elements  of  layers  We  may  formalize  this  de¬ 

scription  in  Z  as  follows: 

e  •  Layer  (e)=k  (5.1) 

(i.e.,  each  element  is  defined  in  exactly  one  layer),  and 

'ix,y  •  (5.2) 

Depends(x, y)=^  Layer (x)>  Layer (y) 

(i.e.,  the  definition  of  each  element  may  “depend”  only 
on  the  definition  of  elements  of  same  layer  or  of  lower 
layers.) 

Corollary  3.  “Layered  architecture”  is  intensional  and 
non-local. 

It  is  obvious  that  an  unbounded  number  of  programs 
can  satisfy  the  conjunction  of  formulas  (5.1)  and  (5.2), 
hence  it  is  intensional.  To  prove  that  it  is  non-local  we 
show  that,  given  any  design  model  that  satisfies  this  style, 
the  same  design  model  can  be  extended  with  a  new  ele¬ 
ment  in  the  lower  “layer”  such  that  this  element  depends 
on  a  higher  layer,  thereby  violating  the  specification. 

We  conclude  that  we  may  selectively  apply  a  non-local 
specification  only  to  certain  parts  of  a  program.  But  what 
does  it  mean?  Does  it  compromise  our  results? 


Figure  3.  A  partially-layered  program.  Only  some 
parts  of  program  satisfy  Layered  Architecture,  but 
Pt  as  a  “program”  does  not  satisfy  the  architectural 
style. 


Discussion.  Is  it  possible  for  a  non-local  specification, 
such  as  layered  architecture,  to  be  applied  only  by  one 
part  of  a  program?  Obviously.  That  simply  means  that 
parts  of  this  program  satisfy  the  non-local  rule,  while 
other  parts  violate  it.  In  fact,  this  property  is  exactly  what 
makes  the  layered  architecture  non-local:  We  say  that  it  is 
non-local  because  it  may  be  violated  anywhere.  Figure  3 
and  the  discussion  which  follows  it  illustrate  this  argument 
using  the  Layered  Architecture  style.  Does  it  mean  that 
non-locality  is  meaningless?  Not  at  all.  Non-locality  is  a 
property  of  a  specification,  i.e.,  of  an  expression;  and  by 
our  thesis,  architectural  specifications  are  always  non¬ 
local.  However,  an  architect  may  choose  to  apply  a  speci¬ 
fication  only  to  some  parts  of  the  system,  and  violate  it  in 
others. 

To  summarize,  it  is  not  meaningless  or  contradictory  to 
state  that  architectural  specifications  can  be  applied  selec¬ 
tively  such  that  they  are  violated  by  some  parts  of  a  spe¬ 
cific  program.  In  such  a  case,  we  say  that  the  style  no 
longer  characterizes  this  program  (as  a  whole.)  Formally: 

Corollary  4.  If  a  specification  Lp  is  (deliberately)  violated 
in  module  m  of  program  TT,  then  either  one  of  the  follow¬ 
ing  is  true: 

■  ^  is  not  satisfied  by  TT,  or 

■  m  is  not  considered  part  of  TT  (i.e.,  it  belongs  to  a  sepa¬ 
rate  program.) 

In  the  example  of  Layered  Architecture  (Figure  3),  a 
module  that  does  “layer  bridging”  (i.e.,  violates  the  layer¬ 
ing  principle)  should  not  be  considered  as  part  of  the  lay¬ 
ered  program;  instead,  we  perceive  it  a  separate  program. 

While  this  conclusion  may  seem  counter-intuitive  at 
first,  it  is  actually  a  powerful  view  on  exceptions  to  archi¬ 
tectural  constraints.  A  module  that  does  layer  bridging 
requires  different  reasoning  and  management  than  the  rest 
of  the  layered  system.  It  not  only  should,  but  also  must,  be 
treated  as  an  exception,  or  else  the  power  of  the  layering 
is  compromised.  Exceptions  to  an  architectural  style 
should  have  attention  called  to  them  and  be  made  the  fo¬ 
cus  of  intense  analysis.  Our  reasoning  provides  a  sound 
basis  for  saying  when  a  portion  of  a  program  is  an  excep¬ 
tion  to  an  architectural  style. 

6.2  Pipes  and  Filters 

According  to  Garlan  and  Shaw  [16],  “In  a  pipes  and 
filter  style  each  component  has  a  set  of  inputs  and  a  set  of 
outputs.  A  component  reads  streams  of  data  on  its  inputs 
and  produces  streams  of  data  on  its  outputs.”  Dean  and 
Cordy  [6]  present  a  visual  formalism  defined  as  a  context- 
free  grammar,  and  formulate  the  pipes  and  filter  style  as 
depicted  in  Figure  4.  Their  specification  is  explained  in 
Figure  5  in  more  intuitive  terms. 


(6) 


More  generally,  a  “program”  in  STSA  (*)  is  repre¬ 
sented  as  a  typed,  directed  multigraph.  An  architectural 
style  is  defined  as  a  context-free  language.  Thus,  an  ex¬ 
pression  in  STSA  defines  a  collection  of  graphs  in  a  visual 
notation,  such  as  Figure  4.  According  to  [6],  a  “program” 
satisfies  the  pipes  and  filters  architecture  if  it  “parses” 
Figure  4.  Figure  5  illustrates  the  kind  of  programs  that 
parse  the  grammar  defined  in  Figure  4. 


Figure  4.  Pipes  and  Filters  (adapted  from  [6]):  Cir¬ 
cles  represent  tasks,  arrows  represent  streams.  The 
plus  sign  is  the  BNF  symbol  for  “one  or  more.” 


Figure  5.  The  general  structure  of  programs  that 
parse  Figure  4. 

Before  we  can  reason  about  Figure  4,  we  must  estab¬ 
lish  which  design  models  satisfy  an  STSA  diagram.  For 
the  purpose  of  our  discussion  in  this  section,  it  suffices  to 
restrict  ourselves  to  multigraphs  that  contain  “tasks”  and 
“streams”.  More  specifically,  let  G  designate  a  multigraph 
whose  nodes  are  “tasks”  and  whose  arcs  are  “streams”.  In 
the  denotation  we  choose,  tasks  and  streams  are  mapped 
into  atoms.  The  relations  we  have  in  our  respective  design 
model  consist  of 

■  the  unary  relations  Task(x)  and  Stream(x),  and 

■  the  binary  relation  Conn 

which  indicate  that  the  directed  arc  representing  stream 
X  terminates  at  the  node  representing  task  y  (or  that  the 
directed  arc  representing  stream  y  begins  at  the  node  rep¬ 
resenting  task  X.) 

It  is  easy  to  see  that  the  general  form  of  programs  that 
parses  Figure  4  is  that  of  a  directed  multi-path,  as  depicted 
in  Figure  5,  and  that  the  design  models  of  these  programs 
have  the  general  form  illustrated  in  formula  (6). 


*  In  absence  of  an  explicit  name,  we  use  the  initials  of  the 
title  of  [6]  with  reference  to  the  formalism. 


Connect(T,,Si  i),...  Connect(Tj,Sj  „j),  ... 

Connect(Si j,  Tj,),...  Connect(Si  T2), 

Connect(T^,S^j),  ...  Connect(T^,S^  „J ,  ... 

Connect(S,  j,T,^j),...Connect(S,„„T,^j) 

Corollary  5.  “Pipes  and  Filters"  is  intensional  and  non¬ 
local. 

It  is  obvious  that  an  unbounded  number  of  programs 
satisfy  formula  (6);  therefore,  it  is  intensional.  To  show 
that  (6)  is  non-local,  observe  that,  for  any  design  model 
that  satisfies  (6)  we  can  add  a  new  task  that  is  not 
connected  to  any  other  task  by  a  pipe.  Such  addition  vio¬ 
lates  the  style’s  specification  (in  particular,  there  would  be 
no  Connect  relation  involving  Since  this  is  a  viola¬ 

tion  wherever  it  occurs,  the  Pipes  and  Filters  style  must  be 
non-local. 

6.3  Law  of  Demeter 

We  have  now  shown  that  two  classic  architectural 
styles  meet  our  criteria  for  being  “architecturaf’  as  ex¬ 
pected.  But  our  criteria  also  turn  up  some  less  expected 
results:  The  Law  of  Demeter  [20]  was  created  as  a  design 
heuristic.  It  was  introduced  to  simplify  modifications  to  a 
program  and  to  reduce  its  complexity.  The  informal  de¬ 
scription  of  the  law  for  functions  is  given  in  Table  4. 

We  may  formulate  the  language  of  Table  4  as  follows: 

V  fl,f2,C  1,0,2  •  (7) 

Member (fj,Cj)  A 

Member(f2,C2)A 

Invoke  (f,f 2) 

Member(c2,Ci)  V  ArgOf(fi,C2)  V  Cj  =  Cj, 

Evidently,  formula  (7)  has  infinitely  many  instances, 
hence  it  is  intensional.  It  is  also  non-local.  To  prove  this, 
observe  that  any  program  that  satisfies  (7)  can  be  ex¬ 
panded  with  source  code  that  violates  the  Law,  such  as 
demonstrated  by  the  C-H-  source  code  in  Table  5. 

Table  4.  Law  of  Demeter  for  functions 

For  all  classes  C,  and  for  all  methods  M  attached  to  C, 
all  objects  to  which  M  sends  a  message  must  be  instances 
of  classes  associated  with  the  following  classes: 

The  argument  classes  of  M  (including  C). 

The  instance  variable  classes  of  C. 

(Objects  created  by  M,  or  by  functions  or  methods  that 
M  calls,  and  objects  in  global  variables,  are  considered 
arguments  of  M.) _ 


Table  5.  An  add-on  to  a  C-i-i-  program  which  violates 
the  Law  of  Demeter 

'  struct  NewNamel  { 
void  foo(); 

I 

!  struct  NewName2  { 

NewNamel  y; 

I 

!  class  NewNameS  { 

NewName2  x; 
void  bar  ( )  { 

x.y.foo  0 ; 

} 


In  conclusion,  the  Law  of  Demeter,  created  as  a  design 
rule,  can  be  better  characterized  as  an  architectural  rule. 
The  Law  is  not  be  limited  to  one  part  of  the  system  but 
must  be  satisfied  throughout.  In  practice,  this  means  that 
any  system  using  the  Law  of  Demeter  must  create  appro¬ 
priate  architectural  practices  to  enforce  it  via  coding  stan¬ 
dards,  design  walkthroughs,  tool  support,  etc. 

This  example  demonstrates  the  benefit  of  making  our 
distinctions  explicit  and  the  power  of  rendering  them  pre¬ 
cise,  without  which  we  would  be  unable  to  classify  the 
Law  of  Demeter  conclusively. 

7.  Analysis 

Clearly,  results  obtained  from  the  case  studies  in  Sec¬ 
tions  5  and  6  are  not  coincidental.  The  same  line  of  rea¬ 
soning  used  for  the  Factory  Method  can  be  used  for  many 
other  (if  not  all)  of  the  design  patterns  in  [14],  as  well  as 
for  the  architectural  styles  by  Garlan  and  Shaw  [16].  Ex¬ 
amples  drawn  from  other  formal  languages  proposed  for 
the  specification  of  design  patterns,  such  as  Constraint 
Diagrams  [19],  DisCo  [22],  and  Contracts  [17],  bring 
forth  sample  specifications,  are  clearly  intensional  as  well. 
This  motivates  the  following  hypothesis: 

The  hypothesis  of  intensional  specifications.  All  “design 
patterns”  and  “architectural  styles”  are  intensional. 

A  direct  proof  of  this  requires  a  formalization  of  “all” 
design  patterns  and  architectural  styles.  The  first  problem 
with  this  is  that  no  given  catalogue  purports  to  contain 
“all”  patterns  and  styles,  nor  do  we  expect  such  a  cata¬ 
logue  to  be  possible  (except  perhaps  in  the  analytic  sense.) 
Another  problem  arises  from  the  mostly  informal  defini¬ 
tions  given  to  patterns  and  styles.  Limited  attempts  have 
been  made  to  prove  this  hypothesis  (e.g.,  [13]  [9]),  but  the 
proofs  provided  cannot  cover  all  known  patterns  and 
styles.  That  is  why  the  “hypothesis  of  intensional  specifi¬ 
cations”  remains  a  hypothesis. 


7.1  Specific  “Designs”  and  “Architectures” 

With  the  increase  in  popularity  of  the  terms  and  their 
proliferation  in  the  literature,  they  often  appear  in  a  con¬ 
crete  context,  such  as  “the  design  of  this  program...”  This 
usage  implies  that  these  terms  can  also  be  used  with  refer¬ 
ence  to  extensional  specifications,  but  only  when  referring 
to  a  concrete  program.  We  suggest  that  “the  design  of 
program  x”  refers  to  the  instance  implemented  in  a  pro¬ 
gram  of  a  general  design  rule  (e.g.,  design  pattern).  Since 
instances  are  extensions,  this  resolves  the  apparent  diffi¬ 
culty  in  the  intension/locality  thesis. 

7.2  UML  Class  Diagrams 

Since  UML  is  used  widely  as  a  design  and  architectural 
notation,  it  is  of  particular  interest  to  understand  the  place 
of  UML  diagrams  in  the  classification  we  introduced:  Are 
they  local?  Intensional? 

Despite  the  widespread  attempts  towards  rendering  the 
notation  with  well-defined  semantics  (e.g.,  the  research 
group  known  as  pUML  [27]),  most  types  of  UML  dia¬ 
grams  have  no  well-defined  semantics.  Thus,  our  discus¬ 
sion  here  is  largely  informal,  assuming  that  any  formal 
interpretation  for  class  diagrams  will  be  consistent  with 
the  informal  semantics. 

In  terms  of  design  models,  we  can  assume  that  any 
such  interpretation  will  associate  class  icons  with  atoms  of 
type  class,  operations  with  atoms  of  type  method,  as 
well  as  provide  us  with  a  specification  of  a  set  of  associ¬ 
ated  relations.  It  is  easy  to  see  why  the  specification  given 
by  a  class  diagram  is  local;  but  is  it  intensional? 

To  answer  this  question,  note  that  a  UML  class  dia¬ 
gram  is  commonly  viewed  as  an  under-specification, 
namely,  an  incomplete  specification;  the  actual  implemen¬ 
tation  of  the  diagram  may  have  any  number  of  additional 
elements  that  are  not  mentioned  in  the  diagram.  Under  this 
assumption,  UML  class  diagrams  are  intensional,  since 
there  exists  an  unbounded  number  of  elements  that  can  be 
added  to  any  implementation. 

Unlike  the  formulas  used  in  our  examples,  however, 
the  abstraction  that  class  diagrams  provide  is  of  the  most 
rudimentary  type,  that  is,  by  omitting  information  but 
without  using  free  variables.  A  UML  diagram  provides  no 
information  on  the  elements  that  are  not  explicitly  de¬ 
scribed.  Thus,  class  diagrams  are  intensional  only  in  a 
trivial  sense,  in  the  same  way  that  the  code  excerpts  in 
Table  2  and  Table  3,  if  taken  not  as  complete  programs 
but  just  as  excerpts  thereof,  are  intensional.  Clearly,  this 
sense  is  unlike  the  way  architectural  and  design  specifica¬ 
tions  are  intensional.  The  following  definition  facilitates 
this  distinction: 


Definition  IV.  An  intensional  specification  Lp  is  quasi- 
extensional  iff  the  set  of  design  models  that  satisfy  ip,  has 
a  single  lower  bound  with  respect  to  the  partial-ordering 
relation  “subsumption 

It  is  trivial  to  show  that  subsumption  induces  partial 
ordering  on  a  set  of  design  models.  Definition  IV,  how¬ 
ever,  assigns  specific  importance  to  sets  of  design  models 
that  contain  design  model  such  that  all  other  members 
subsume  it. 

Corollary  6.  UML  class  diagrams  are  quasi-extensional. 


Figure  6  illustrates  the  proof  to  this  corollary.  It  is  triv¬ 
ial  to  show  also  that  none  of  the  intensional  specifications 
we  quoted  above  is  quasi-extensional. 


Figure  6.  The  design  models  that  satisfy  a  UML  class 
diagram 


8.  Conclusions 

We  have  provided  a  sound  formal  basis  for  the  distinc¬ 
tion  between  the  terms  architecture,  design,  and  imple¬ 
mentation,  called  the  intension/locality  thesis,  and  estab¬ 
lished  it  upon  best  practices.  What  are  the  consequences 
of  precisely  knowing  the  differences  between  the  terms 
architecture,  design  and  implementation?  Among  others, 
these  distinctions  facilitate  - 

■  determining  what  constitutes  a  uniform  program,  e.g.,  a 
collection  of  modules  that  satisfy  the  same  architectural 
specifications; 

■  determining  what  information  goes  into  architecture 
documents  and  what  goes  into  design  documents; 

■  determining  what  to  examine  and  what  to  not  examine 
in  an  architectural  evaluation  or  a  design  walkthrough; 


■  understanding  the  distinction  between  local  and  non¬ 
local  rules,  i.e.,  between  the  design  rules  that  need  be 
enforced  throughout  a  project  versus  those  that  are  of  a 
more  limited  domain. 

For  example,  in  the  industrial  practice  of  software  ar¬ 
chitecture,  many  statements  that  are  said  to  be  “architec¬ 
tural”  are  in  fact  local,  e.g.,  both  tasks  A  and  B  execute 
on  the  same  node,  or  task  A  controls  B.  Instead,  a  truly 
architectural  statement  would  be,  for  instance,  for  each 
tasks  A,B  which  satisfy  some  property  p,  A  and  B  will 
execute  on  the  same  node  and  Control(A,B).  More 
generally,  for  each  specification  we  should  be  able  to  de¬ 
termine  whether  it  is  a  design  statement,  describing  a 
purely  local  phenomenon  (and  hence  of  secondary  interest 
in  documentation,  discussion,  or  analysis),  or  whether  it  is 
an  instance  of  an  underlying,  more  general  rule.  (*) 
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